Ham Radio 2000 #1/Ham Radio 2000.iso/ham2000/packet/terminal/paket61/man05.doc

Text File | 1994-08-15 | 119.7 KB | 3,697 lines

PART V - Messages in the paKet system
Overview

 This is a list of messages in the paKet system. They are listed in
 alphabetic order.

 Most messages will appear in the Message Window. That window will stay
 on the screen for a short time before it disappears to allow normal
 processing to continue.

 However, some messages might require some action on your part; or they
 might be messages that I thought could take a little longer to digest.
 Those messages will remain on the screen and will appear with a prompt
 for you to press the <Enter> key when you are ready to continue.

 Some paKet users have asked that the messages stay on the screen for a
 bit longer to give them more time to read the message.  Others have asked
 that the messages clear more quickly so they can get on with the job!  I
 know it is dangerous to try to please everybody, but I have added another
 option to allow you to choose your own message duration - check out the
 "Message duration" option in the Miscellaneous Configuration Window. You
 might like to note that if you have a message on the screen and want to
 get rid of it before its "duration" has expired, you can press the <Esc>
 key to clear it off the screen.

 Many of the messages that appear are routine information messages that
 require no action on your part.  They are there to let you know what is
 happening in the system.  Other messages are warnings or even serious
 errors and are things you really should know about.   As you gain
 experience with the paKet system you might find some of the routine
 information messages are not really required any more; they might even
 become a little tiring.  If you would like to remove those Information
 messages, you can adjust the "Msg level" option in the Miscellaneous
 Configuration Window.  There are three levels there - the normal setting
 is A so All messages are displayed.  You might like to change it to W so
 only the Warning and Error level messages appear.   Personally, I prefer
 the All option so all messages appear, and sometimes reduce the "Message
 duration" rather than remove them altogether with the "Msg level" option.
 But the choice is yours.


 Some of the messages listed in this section appear in the Communications
 Window.  For example, some are sent to a REMOTE operator who might be
 accessing this system in your absence.










                               Page 157

Messages starting with A

 A disk error has occurred here.

   This message can come from a number of processes within the paKet
   program.  Usually it means just what it says.  Sometimes it will be
   followed with additional information that might help you to identify
   just what is wrong.

   For example, if you were saving a message to your Personal Message
   System (PMS) it will add: "Your message is not saved."

   Usually it will be obvious what operation caused the error.  The
   message will appear immediately the operation is attempted so you will
   know that (for example) if you just tried to create a new Log File with
   the <F2> key and this message appears, then there is something wrong
   with that Log File operation.

   Typically a disk error is something as simple as a lack of space, a
   write protected diskette, lack of privileges to access a network
   device, etc.  It can also be caused if a new file is to be opened and
   you have insufficient FILE handles available - increase the FILES
   parameter in your CONFIG.SYS file if necessary.

   If it is a genuine disk error other messages will appear and you will
   probably be getting various errors when running other programs.


   This message can be issued to a REMOTE user too if some attempted
   REMOTE operation fails.



 A smaller version of this file exists.
 I will attempt a paKet-Protocol Recovery

   This message could appear if a Binary File is being transferred to our
   system and both stations are equipped to handle the advanced paKet
   Protocol.

   The situation that causes this message is where the file being
   transferred already exists on our system but our file is shorter than
   the one about to be sent by the other station.   This could happen if
   an earlier file transfer was aborted for some reason and so our file
   would be incomplete.

   This message informs you that paKet is asking the other station to
   check the details to see if a Recovery is possible.






                               Page 158

 A Multiple of 16K allows more efficient use of EMS memory
 Eg: 16, 32 48 or 64K

   This message might appear after you change the Flashback Buffer size in
   the Communications Windows Configuration.

   If you have EMS memory available paKet can use some of it for Flashback
   buffers.  The program manages pages of EMS memory in multiples of 16KB
   so if you specify some other figure, you will not be making best use of
   your available memory.
   You may ignore the message if you wish, but it is recommended you
   reconfigure the Flashback Buffer size to one of the above figures.



 Abort, Retry, Ignore <R>

   An error has occurred. You have three options: A, R or I...

   A(bort) the program. If you select this option, paKet will simply give
   up, and return to DOS. As this is a rather serious step, paKet will
   seek your confirmation that this is really what you want to do by
   prompting you with the following question:

      Aborting paKet and returning to DOS...  Are you sure? <N>

      If you then reply "Y", everything stops and you will be returned to
      the DOS Prompt.  It is nice to have a way out in case of a really
      serious problem but I expect this option would be rarely required.

   R(etry) the operation that caused the error. This is the default
   response so if you simply press <Enter>, paKet will assume a Retry. In
   most cases I hope this will get you going again. For example it might
   be a diskette problem such as "door not closed", "write protect tab",
   etc so you can attend to the problem, select Retry and things should
   proceed normally.

   I(gnore) the problem.  An error message is like pain: it is there for a
   reason and should not be ignored.  But if you are sure you know what
   the problem is and choose to ignore it, you can select this option and
   paKet will try to continue despite the error.  However, do this at your
   own peril and don't call me if you get into trouble!



 Aborting at end of block...
 Press <Esc> again to force immediate end of the transfer

   When you are performing a Binary File Transfer using the YAPP or the pP
   protocol, data is sent in blocks of up to 254 bytes each.  The data in
   each block may contain any value at all so if we need to send a <CANCEL>
   code to the other station in the middle of a transfer, that station will
   not be able to determine whether that code is really a <CANCEL> or just
   another data byte in the file that happens to have that same value.
                               Page 159


   So if you do decide to Abort a file transfer by pressing the <Esc> key,
   paKet will not issue the <CANCEL> code immediately.  It will wait until
   the end of the block currently being sent, before transmitting the
   <CANCEL> code.  That way, the other station has a better chance of
   recognising the <CANCEL> code.

   This message is displayed to acknowledge the Abort request and to let
   you know what is going on.

   If there is some problem with the transfer and it appears to be locked
   up, or if the other station is not responding, you can press <Esc> a
   second time and force an immediate abort.



 Aborting...

   Refer to the above message.

   When the <CANCEL> code is sent to the other station, this message
   appears to let you know it is done and that we are now waiting for the
   other station to acknowledge that command before we continue.



 Alerts now enabled but will not sound while QUIET mode is on

   This message can appear after you press <Alt-A> to enable Alerts Mode.

   The Alerts facility in paKet monitors data coming and going in the
   Communications Window and sounds the bell when some predefined string
   of characters appears.  The predefined strings are specified in the
   Configuration under the "KB Macros/Auto commands" section.

   However, paKet also has a Quiet Mode option (refer <Alt-Q> key) where
   ALL sounds are disabled with a single keystroke.  If you happen to
   enable Alerts at a time when Quiet Mode in on, this message appears to
   warn you paKet will not be making any sounds even if the specified
   Alert string is detected!



 ... already exists.  Message NOT copied!

   Eg:
   VK2DHU.123 already exists.  Message NOT copied!

   In paKet's PMS there is a Copy function which allows you to copy any
   message in the PMS to a data file on disk.

   The PMS and the Copy command are discussed more fully in the PMS
   Section of this Manual.  But briefly, you can type "C 123" at the Sysop
   PMS Menu and paKet will copy the contents of message 123 to disk.  The
                               Page 160

   name of the new disk file will consist of the callsign of the station
   the message is addressed to; and the extension of the file will be the
   message number.  For example, if message number 123 is addressed to
   VK2DHU, the new disk file will be VK2DHU.123.

   If you try to do the copy again, paKet will not overwrite that disk
   file.  Instead it warns you with the above message.  You should either
   delete or rename that existing disk file before trying the Copy
   function again.



 Another station is currently connected.
 Please try again later

   Although paKet can handle up to 10 simultaneous sessions with 10
   different users, there is a problem when a REMOTE user tries to perform
   a Binary File Transfer.

   The standard TAPR TNC, on which all modern TNCs are based, can run in
   either Converse Mode or Transparent Mode, but not both!  Converse Mode
   is used for normal conversation and Transparent Mode is required for
   Binary File Transfers.  So if a standard TNC is switched into
   Transparent Mode, ALL sessions are switched into Transparent Mode,
   including those other sessions currently in Converse Mode!  And vice
   versa...   This is a limitation of the standard TNC and as paKet is
   written to support the standard TAPR compatible TNC, there is not much
   I can do about this problem.

   Therefore the program will not allow a REMOTE user to initiate a Binary
   File Transfer while there is any other station connected at the time.
   The above message is issued if such an attempt is made.

   If YOU decide to initiate a Binary File transfer while connected to
   someone else in another Window, I can only assume you know what you are
   doing!  The program will allow this to continue, but I hope you DO know
   what you are doing!



 Appending to existing file ..."

   This message appears when you are starting the Log file or are writing
   the Flashback buffer to disk if paKet finds the specified file is
   already on the disk.

   paKet will preserve the contents of that file and will write the new
   data to the end of this file.

   No action required.




                               Page 161

 ASCII file command must be AD, AC or AU

   The Script file you have just loaded contains a command beginning with
   A but it is not one of the valid ASCII file transfer commands.

   The Script has been aborted.  Edit the Script file to correct this
   invalid line and run the Script again.















































                               Page 162

Messages starting with B and C

 Bad copy of program.  Reinstall paKet from original diskette

   Something is wrong with the copy of PAKET.EXE you are running.  It is
   hard to know what could have caused the corruption so the safest option
   at this stage is to reinstall a fresh copy from the original diskette
   or from your backup copy.



 BaycoM command must be MW, MD or MU.

   A REMOTE user has issued a command beginning with M but paKet has
   failed to recognise it as one of the valid commands.  Normally M is
   used for the BayCom file transfer commands so paKet issues the above
   message to help the REMOTE user with the required syntax.




 Before registering, please enter your Call Sign in the
 Configuration's Miscellaneous options (<Alt-Z> then 9)

   You typed <Alt-R> to register the program but I need to know your
   callsign to confirm whose copy this is.  Enter your callsign in the
   Miscellaneous Configuration Window and paKet will then ask for your
   serial number.



 Buffer Search
 Please enter the search string  -

   When you wish to search backwards through the Flashback buffer for a
   particular string of characters, this message will prompt you for the
   data to search for.

   This is not case sensitive so it doesn't matter if the data is in upper
   or lower case, if it is spelt the same it will be matched!

   Refer to the section on the <Alt-F> and <Alt-L> keys for further
   discussion on this facility.



 CFG file error - incorrect version

   This message is displayed on the DOS screen immediately prior to the
   program's return to the operating system.  If the config file is not
   the correct version, paKet does not know what parameters to use so it
   aborts before it gets started!


                               Page 163

   The version number appears in the first line of the CFG file and must
   be the same as the current version of the program.

   If you have no backup of the correct CFG file, run INSTALL again to
   rebuild the CFG file.



 CFG file error

   This error will appear immediately after you attempt to start the
   program if there is something wrong with the PAKET.CFG file. It will
   not even appear in a pop-up window because those windows will not have
   been created yet.

   The error message could be followed by further details such as:
      "invalid Keyword ignored"
      "no keyword"
      "invalid colour"
      "invalid data"
      "too many beginning commands"
      "too many ending commands"
      "too many alerts"

   In any case, the offending line in the config file will be displayed
   to help you identify the fault.

   You should never see any of these messages because the config file is
   managed by the program itself and it can be expected to do the job
   correctly.  You should have no need to manually edit the file.  (Er, no
   offence, but I suspect the only way the config file will be corrupted
   in this way is if someone tries to edit the file with their text editor)

   There is a section in this Manual covering the Config File, and
   discusses the various parameters.  This was included for completeness
   of the program documentation and for those who are interested in the
   workings of the system.  It is not included as an invitation to fiddle!



 Closing existing file capture

   You are running a Script and paKet finds an AD command in that Script.
   (That AD command is used to open a file for an ASCII Text Download)
   If there is already a Text file download in progress, paKet will close
   that existing file before opening the new file specified in the AD
   command.

   The above message appears to inform you of the action being taken.  You
   do not have to do anything.




                               Page 164

 Closing log file (filename)

   This is a message to confirm the Log File is now being closed.

   This message could appear after you close the Log File with the <F2>
   key or if the file is closed automatically by the AUTO log function
   when a station is Disconnected.

   No action is required unless you want to continue logging, in which
   case you should manually reactivate the Log File with the <F2> key.



 COMx is not installed. Try another? (Y/N)

   When paKet starts, one of the first things it does is to set up the
   Computer's Serial port. It tries to initialise the port you have
   specified in your Configuration but if that port is unavailable, this
   message appears to give you the opportunity to try another one.

   This condition should rarely occur but is possible if you have changed
   your Computer's hardware or if you have copied a Configuration File
   from another system.

   Anyway, no harm is done as paKet will cycle through all the Serial
   Ports until it finds the one you wish to use.

   You should check the rest of the Configuration, especially the Serial
   Port details once the system starts up.  If the Port number was wrong,
   it is possible other parameters will need adjustment too.



 Confirming...Connected to (callsign)

   After pressing <Alt-V> to verify the connected status, this message
   will appear if the TNC agrees with the callsign already displayed in
   the Communications Window Header line.

   No action required.



 Confirming...Not Connected

   After pressing <Alt-V> to verify the connected status, this message
   will appear if there is currently no connection and the TNC has simply
   confirmed this.

   No action required.




                               Page 165

 Corrupted PAKETCFG.HLP file

   The PAKETCFG.HLP file contains help information that may (optionally)
   be displayed while you are accessing the Online Configuration Windows.

   You should not see this error message at all - if it does appear, it
   suggests someone has modified the file!

   Extract the original file from your original paKet diskette or from
   your backup copy.












































                               Page 166

Messages starting with D and E

 Deleting (filename) - Are you sure? (Y/N)

   If you attempt to delete a file, paKet will ask for confirmation before
   it performs the deletion. You have one final chance!

   Enter "Y" to carry out the deletion.



 Disk error on drive X

   Unfortunately this means just what it says.

   This error condition is returned by the DOS operating system. The causes
   are many and varied so you should perform the usual checks to try to
   identify the cause.  Typically the error is related to the lack of space
   on a disk or diskette, or perhaps a diskette drive door was opened.

   If there really is a fault with the disk you will be getting similar
   error messages when you are running other programs. In that case
   specialist attention is required.

   The error message is usually followed for some additional information
   returned by the Operating System, such as:
           "Write protected"
           "Unknown unit"
           "Drive not ready"
           "Unknown command"
           "Data Error (CRC)"
           "Bad Request"
           "Seek Error"
           "Unknown media type"
           "Sector not found"
           "Printer out of paper"
           "Write fault"
           "Read fault"
           "General failure"
           "Unknown error type"

   and you will usually be given the following options:
           "Abort, Retry, Ignore <R>"

   Check the DOS documentation for further information, and refer to the
   description on the "Abort, Retry, Ignore" message for discussion on the
   options available.







                               Page 167

 Displayed Callsign changed to match the TNC

   After pressing <Alt-V> to verify the connected status, this message
   will appear if the TNC indicates we are connected to a station other
   than that indicated in the current window's Communications Window
   Header.

   No action required.



 Download commenced
 Download successful
 Download UNSUCCESSFUL

   These advisory messages appear in a System Note which is displayed in
   the Communications Window (and in your log if the Log File is active at
   the time) when a Binary File Transfer is performed.

   The messages are produced mainly to cover those situations where the
   file is transferred by a REMOTE operator or from within a Script file.
   In other words, at a time where you are not present to see the activity
   and I thought it would be helpful to be able to scroll back into the
   Flashback buffer or to check the log to determine the success or
   otherwise of the transfer.



 Enter a DOS command, or press Enter for a DOS window.
 >

   When you want to exit to DOS to perform some program or DOS command you
   can do it in one of two ways:

    1.  You may enter the command into the message window beside the
        ">" prompt.

        If you do this, the command will be executed (if possible) and you
        will be invited to "Press any key to continue" before paKet
        resumes where it left off.  The "Press any key to continue"
        message appears briefly over the DOS display to allow you time to
        peruse the result of the job and to read any messages etc that may
        have come from the DOS command.

     2. Press <Enter> instead of entering a command, and the screen will
        be cleared before control is passed over to DOS and the familiar
        DOS Prompt.

        When you have finished the DOS operations, type EXIT to return to
        paKet.  Do NOT type PAKET again as the system will attempt to load
        a second copy of paKet into memory!

    Please keep in mind that paKet is still in memory at this stage,
    gathering any incoming data that may be sent from the TNC while you are
                               Page 168

    doing your DOS jobs. So you will have considerably less free memory for
    your other DOS programs and may even find some will not run due to
    insufficient memory. The only remedy for this, I am afraid, is to
    return to paKet and exit the program so you can release the memory
    occupied by paKet.

    If you are running paKet from a Multi Tasking system such as OS/2, or
    perhaps as a DOS task under Windows Enhanced Mode, DESQview, etc it
    would be better to simply use the system to start another DOS task and
    run your other program from there.  That way, you will have the full
    facilities of the system and probably full memory etc.  Check your
    system parameters to ensure paKet's task continues to share the CPU
    while in the "background" otherwise you could lose any data that might
    be sent from the TNC.



 Enter any command you want sent to the other station (Esc if none).

   There is a RAW Binary File Transfer mode available in paKet.  This mode
   is provided to cover those situations where you need to conduct a
   Binary File transfer with some other computer system that does not
   support pP, YAPP or BayCom file transfer protocols.

   With the RAW mode there is no protocol used at all so there is no
   handshaking performed by the system - it is up to you to do it all
   manually.

   One of the things you might need to do after initiating the transfer is
   to send some command to the other system to get its end of things
   going.  So this message will appear to allow you to enter that other
   command and if entered, that data will be sent to the other station
   before paKet switches over to Transparent Mode for the File Transfer.



 Enter new Path\Filename for (filename)

   When you select a file to be Renamed or Moved to another directory
   (with the <Alt-R> key), paKet will ask for the new name.

   In response to this message, enter the new filename or, if you wish to
   move it to another sub directory, enter the full path details. For
   example: \PAKET\BINARY\UTILS\USEFUL.COM

   If the Rename or Move cannot be performed you might see one of the
   following self explanatory messages:
      "No such file or directory"
      "I can't do that."
      "Maybe that file exists?"
      "I can't MOVE to a different device!"



                               Page 169

 Enter Path:

   When you choose to "Enter file name manually" from the Directory Window
   you will be asked to enter the details of the desired file in this
   Message Window.

   Any valid file name may be entered here, including a drive and/or
   directory together with the desired filename.



 Error closing the log file

   The operating system has detected an error while closing the Log File.

   Check the usual things (available space, diskette drive door open, etc)
   and be warned that you could have lost some of the log file with this
   error.

   Processing will continue without the Log File.



 Error in Script JUMP command

   This message appears when you run a Script but the program finds some
   syntax error in your Script file.  In this case the error is in a JUMP
   command.

   Refer to the section on Scripts in this manual for a discussion on the
   correct syntax requirements.



 Error saving Configuration. No changes saved.

   If you make any changes to paKet's Configuration, the changes are
   automatically saved to disk, but if this message occurs, the latest
   changes to the Configuration have NOT been saved.

   Processing continues, but you should check your system to see why the
   error occurred. The possible causes are many and varied but if you are
   not having other problems this could be as simple as running out of
   space.



 Error setting new directory

   When the Directory Window is on the screen, you may change directories
   by highlighting a sub directory entry (shown as "<DIR>") then pressing
   <Enter>. The system will change to that directory and will then display
   the contents of that new sub directory.

                               Page 170

   You may also choose another directory by specifying the path manually.

   This error message occurs when the system is unable to change to the
   new directory. As you would usually be changing by pointing to the
   displayed directories, this error should be rare.  It is most likely
   you have typed the path manually and have mistyped something.



 Error writing to file being Received - now closed

   A disk write error has occurred while receiving an ASCII file.

   The file is now closed but is probably incomplete. You should check
   your computer system to see what might have caused the problem.

   Typically this error is caused by a lack of space on the disk or, if a
   diskette is being used, check the diskette is not write protected and
   the drive door is closed.

   When you have corrected the problem, you can try the file transfer
   again.



 EXIT to DOS?
 Press "Y" to Confirm

   After pressing <Alt-X> or <Alt-F4> to exit the program, this message
   will appear asking for your confirmation that this is what you really
   want. It is so easy to press the wrong key (I have done it often).

   If you enter "Y" the paKet program will close down and control returns
   to the DOS prompt (or to the Menu if you loaded paKet from a Menu).

   Type anything else and paKet ignores the Exit request, resuming
   whatever it was doing.

















                               Page 171

Messages starting with F, G and H
 Failed to make window

   There are over 20 different windows used by the paKet system and there
   is some memory allocation and initialisation required to set these up.
   The most likely problem if this message appears is Insufficient Memory.



 File display not available.

   A REMOTE user can request a display of the disk directory on our system
   with the W, MW or YW commands.   paKet prepares the listing in sorted
   sequence as a temporary file on disk, then that temporary file is sent
   to the other station.

   If some disk error occurs during the creation of this temporary file,
   the above message is sent to the other station and the directory
   listing is not sent.

   Action required is similar to that for other disk errors.



 File has no data

   You have selected a file to be sent to another station but this file is
   empty!



 File path is ignored (I will use the file NAME).

   A REMOTE user has issued a file upload command to send a file to our
   system but has included a drive and/or directory name in addition to
   the file name.

   For your protection, paket will not allow uploads into anything but the
   Upload directory you have specified in the Configuration.

   The above message is sent to the other user, but the file transfer
   continues using just the file name specified.  That new file will be
   written into your Upload (receive) directory.



 File write error

   While performing a Binary File transfer a disk error has occurred. As
   various checks are usually performed before the transfer begins, I am
   afraid this message does suggest you have a hardware problem.

   Maybe if you are using diskettes the problem is simply a matter of the
   drive door being open?
                               Page 172




 ... has the telephone bells disabled here, but give it a minute or so..."

   Eg:  Tony has the telephone bells disabled here, but ...(etc)

   If a REMOTE user selects the T(alk) option to leave REMOTE Mode and
   continue in normal conversation mode with you, paKet will usually ring
   the bells to attract your attention.

   If you have the "telephone bells" option disabled or you are running in
   Quiet Mode the program will not ring the bells.  In this case, the
   above message is sent to the REMOTE user for information.



 Hey, we have got more data than the file size expected!
 I can't handle that, so I will abort the transfer

   This should not happen because the system will be expecting the exact
   file size as indicated in the directory. But just in case something
   goes wrong...



 Hey, you can't send the CURRENT log file!
 Think about it...the file will grow as fast as you can send it!

   You wouldn't really try to transmit the current log file, would you?

   Close the Log File, then try again.



 Housekeeping...tidying up the PMS DataBase...

   From time to time, when you are using the Sysop PMS Menu (refer the
   <Alt-M> key) paKet will perform some internal housekeeping to minimise
   any wastage of space in the PMS sub-system. This message appears
   briefly to inform you of this housekeeping.













                               Page 173

Messages starting with I

 I am unable to record your Serial Number
 Try recording your Serial Number with the INSTALL program
 but if no success, contact your official paKet distributor.

   When recording your Serial Number, the program updates itself on disk.
   That is, it writes your Serial Number into the PAKET.EXE file.
   But these messages will appear if it is unable to do so.

   The two most common causes of this error are:

      1. The program is write-protected with the Read-Only attribute or
         it is on a write-protected diskette;  or

      2. You are running the Microsoft SHARE program (usually from
         within your system's AUTOEXEC.BAT file) and SHARE will not
         allow us to write the new serial number into the PAKET.EXE file
         while it is being used!

   If 1, remove the write protect status from the PAKET.EXE file and try
   again.   Please note there is no other form of modification being done
   to the program - it is simply recording the Serial Number.  You may
   still give a copy of your program to others, even with your Serial
   Number recorded.  In fact I encourage you to do so (although I would
   rather you give them a copy of the original distribution diskette just
   to help ensure they get the entire package).

   If 2, SHARE will not allow us to record the Serial Number while paKet
   is running.  You could remove SHARE temporarily, probably by editing
   your AUTOEXEC.BAT and rebooting, or you can register the program from
   paKet's INSTALL program. See the INSTALL.DOC file for details. The
   computer system will be happy to update your copy of the PAKET.EXE
   program from the INSTALL program because then you will not be actually
   running the PAKET program at that time!



 I assume you have ALREADY set the TNC's parameters.

   If you want to change some Serial Port settings, the procedure is
   usually to issue the commands to the TNC then change the computer's
   settings in the Serial Port Configuration Window.

   The TNC will note the changes but not actually use the new settings
   until a RESTART command is issued (some non standard TNCs use RESET but
   RESTART is the most widely used).

   If, after making some changes to the Serial Port Configuration, you
   ask paKet to issue the RESTART command, the above message appears to
   remind you the TNC parameters should have been made already.



                               Page 174

Messages starting with "I can't..."

 I can't append to the file

   A disk error has occurred after choosing to append to the existing
   file. At this stage, we know the file exists so the most likely cause
   would be a lack of space or a genuine hardware error. I hope you are
   out of space!


 I can't create a new PMS DataBase
 I'll try again next time.

   While doing some housekeeping on the PMS DataBase, paKet tried to
   create a new file to contain the "cleaned up" PMS but got a disk error.

   This housekeeping can wait till next time - it is not critical - so
   processing continues. You should check it out as soon as possible to
   see what the problem is.


 I can't create the file

   An attempt was made to create a new data file but it failed.

   You could check to see there is sufficient space available and if you
   are using the Root directory, ensure there are sufficient directory
   entries available.

   If using diskette, ensure the diskette is not write protected and the
   diskette is inserted in the drive with the door closed.

   It should be quite obvious which file paKet is trying to create because
   of other messages that will be displayed and because it is probably the
   result of some command you have given that the file is being created
   anyway.

   If the new file is one specified in the Configuration, for example the
   Connect File, check the details in the Configuration - it may be you
   have specified a drive or directory that does not exist.



 I can't delete this entry

   You may delete a normal FILE from a Directory Window, but you may NOT
   delete a Read-Only, Hidden or System File, nor a Volume Label!



 I can't do that. Maybe that file exists?

   The system returned an error condition when trying to rename a file.

                               Page 175

   Typically this could be because the new name you gave is a file that
   already exists in that directory.  The Rename/Move function is not like
   a COPY command - it will not overwrite an existing file.


 I can't find COMMAND.COM

   You are in big trouble!  The system could not find COMMAND.COM and you
   will not be able to run other DOS jobs without it!

   Usually DOS can find it via the COMSPEC parameter, or maybe in the
   current directory or via the PATH statement.



 I can't find (filename)

   This error message appears after paKet is asked to process this data
   file but the file could not be found.

   It is most likely to appear after you have manually entered a file name.

   Try the operation again, specifying the correct file name, not
   forgetting to specify a path (drive and subdirectory) if necessary.

   The error could also appear after selecting a file which is specified
   incorrectly in the Configuration. For example if the location of the
   TNC Help file is not correctly recorded in the Configuration this
   message will appear when you press <F10> to see the TNC Help file. In
   this case, select the Configuration (<Alt-Z>, then 8) and make the
   necessary corrections before trying the operation again.

   If you are in REMOTE Mode and the other station requests a file
   transfer, this message will be sent to that other station if the
   specified file could not be found.


   If the file paKet is looking for is a Help File, it will probably
   display an additional message such as:
      "I will continue but without the Configuration Help windows"
   and processing will continue, as this error is considered less serious.


   If paKet is unable to find the PAKET.CFG file, this message will be
   displayed immediately prior to control returning to DOS. The CFG file
   should normally be in the same directory as the paKet program, but you
   may specify a different the CFG file, including a path,  on the command
   line if you wish.

   If you would like to have multiple configurations available, for example
   a husband and wife might share the computer for packet operations; then
   each can have their own configuration, not just for things like colours
   but for Operator Name and callsign, etc. Or you might have a different
   setup for VHF and for say HF operations or for PacTOR operations.
                               Page 176


   To specify a different CFG file, specify the name of the desired CFG
   file on the command line.  For example to load and run PAKET with a
   config file of HF.CFG you type the command line as follows:
      PAKET HF
   You do not need to specify the .CFG extension.  If no parameter is
   specified on the command line, paKet will look for a CFG file with the
   same name as the program (i.e. PAKET.CFG) in the same directory as the
   program.


 I can't find (filename). I'll create a new one.

   When you first use the <Alt-C> facility to Connect to another station,
   paKet will fail to find a Connect File and will produce this message to
   let you know it is creating a new one.

   You can enter as many station details as you wish into this window and
   it will be automatically saved to disk using the "filename" specified.
   Next time that file should be found and the message will no longer
   appear.

   There is a possibility the filename is incorrect in paKet's
   Configuration in which case the message will serve as a warning that
   you are not accessing the correct file. Or perhaps the file is on
   diskette and the appropriate diskette is not in the drive. If so, you
   can delete or ignore the new file just created, and insert the correct
   diskette.


 I can't find message nn!

   You have entered a PMS command but the message number you have
   specified does not exist.

   Reenter the command with the correct message number. You could perform
   a List command ("L") to see the available messages.



 I can't find the (filename) Script file.

   If a REMOTE user attempts to Perform a Script on our system, paKet will
   send back this message if that file cannot be found in our Scripts
   directory.


 I can't find the (dir) directory.

   This message will appear if you have manually entered a file name and
   path but the directory could not be found.

   Try the operation again with the correct name.

                               Page 177


 I can't find the program to run

   The "program" in this case could be a program name you have entered at
   the DOS command line provided by paKet's <F9> DOS exit.

   Another possibility is the system could not find the program to Edit or
   to Display a data file if you have used the <Alt-E> or the <Alt-D>
   commands.

   If the message occurs after you select <Alt-E>, check paKet's Online
   Configuration - Directories and Files and correct the System Editor
   entry before trying the operation again.

   If the message occurs after you select <Alt-D>, check paKet's Online
   Configuration - Directories and Files and correct the "Command to list
   a file" entry before trying the operation again.



 I can't MOVE to a different device!

   When moving a file with the <Alt-R> key, the system will not actually
   copy the data, it simply adjusts the directory entry.  As different
   drives have different directories, a "move" is not possible between
   drives. You will have to copy the file to the new drive then (if
   desired) delete the file on the original drive. Use the COPY command
   from the DOS Gateway (refer <F9> key).



 I can't read the message file.
 Ask (your name) to investigate the cause

   A REMOTE operator tried to read a message from our PMS but something is
   wrong with the file.

   Your guess is as good as mine at this stage.  Perhaps you have had some
   problems with the system or maybe you have been adjusting the
   configuration and the files are no longer in the correct directory?

   This message is sent to the other station to let them know they are not
   going to be able to see that message they wanted!



 I can't Rename/Move this entry

   You may Rename or Move a normal FILE in a Directory Window, but you may
   NOT Rename or Move a Hidden or System File, a Sub Directory, nor a
   Volume Label!



                               Page 178

 I can't see CTS signal on the Serial Port!
 Would you like to try Software Handshaking? (Y/N)

   You might need to refer to the discussion on Hardware vs Software
   Handshaking in the Technical Section of this Manual if you have
   difficulty understanding what this is all about.

   If you are using Hardware Handshaking the CTS signal should be present
   when the program starts but paKet has found that signal "missing".

   It is possible the cable used to connect the TNC to the Computer does
   not have this CTS line connected. Such cables are quite common and if
   you have one of these, you must change to Software Handshaking.



   If you reply "Y" paKet will change it's Configuration to Software
   Handshaking and processing will continue. Please ensure the TNC's XFLOW
   command is set ON if you use Software Handshaking - this is especially
   important if you are doing any file transfers.

   If you reply "N" paKet will attempt to continue in Hardware Handshaking
   mode, although without a CTS signal it will be unable to send anything
   to the TNC!   Usually you would select this option after you have been
   able to restore the CTS line and then processing will continue normally.





























                               Page 179

Messages starting with I (cont)

 I did not get the expected response from the TNC
 So, I am not too sure whether we are connected or not!

   When you press <Alt-V> to verify the TNC's connected status, paKet
   issues a command to the TNC and interrogates its response but in this
   case the expected response was not received.

   The displayed callsign is not changed.

   If this happens more than once, it may be the TNC is not responding for
   some reason so you should check that and ensure it is still working for
   normal commands, then try the <Alt-V> again.



 I don't have room for all the help file

   This error message means there are more index entries in the file than
   I have allowed for.

   It is unlikely you will see this message, but if you do it is because
   someone has modified the Help file since I released it.  In that case
   modify it back again, or restore an original copy from the original
   paKet system.



 I have a disk error and cannot record the message.
 Ask (your name) to investigate the cause.

   This message is sent to a REMOTE user when a message is being left on
   our system but paKet is unable to write it to the disk.



 I have ignored this CONNECTED message because
 we seem to be Connected on this stream already!

   A "CONNECTED" message has appeared in the Communications Window but the
   program thinks we are already connected on this stream.

   Usually this string comes from the TNC when a new connection is
   established and paKet detects that particular string of characters to
   determine the callsign of the station we are now connected to.

   Sometimes someone else could transmit some data that happens to contain
   that same string of characters, so when it appears in the Communications
   Window paKet can easily get confused and think the TNC is telling us we
   now have a new connection!



                               Page 180

   If the program thinks we are already connected on this stream it will
   not process this CONNECTED string as a new connection; instead it will
   simply issue the above message to let you know it has been ignored.

   If you wish, you can press <Alt-V> to ask your TNC to verify the
   callsign of the station we are currently connected to.



 I need the file name and the file size.
 Eg: MU PROG.COM,14392
 Enter zero for the filesize if you don't know it's size in bytes.

   A REMOTE user (presumably a BayCom user) is attempting to send a
   Binary File to us but the MU command was incomplete.

   At the time of writing this Manual, the BayCom system does not support
   any Binary File Transfer protocol.  Without a formal file transfer
   protocol, paKet has no way of knowing when the end of the incoming data
   file is reached.

   So, I have implemented a requirement that the file SIZE be specified.
   If the program knows the size of the file, it can count the data bytes
   as they are received and then it will know when to close the file!

   To cover the situation where the file size is not known, the program
   will allow the transfer to proceed if you specify a 0 for the file
   size.  But then you will have to close the file manually.

   For full details on this operation, have a look at the description of
   the <Alt-F8> key in the Keyboard Commands section of this Manual.



 I'll ring the bell. If no response soon, maybe (your name) is not around?

   A REMOTE user has typed a "T" command at the menu to leave REMOTE Mode
   and to talk to you in normal conversation mode.  The above message is
   sent to the other station to acknowledge that command.

   paKet will sound the bell to alert you to this and will remain in
   Converse Mode for a short time to allow you to come to the keyboard.
   If you are not there, the program will return to REMOTE Mode and send
   the menu to the other station.



 Insufficient memory

   There are thousands of places within paKet (well quite a few anyway)
   that could issue this dreaded message.

   In the current version of paKet I have gone to great lengths to
   minimise the chances of getting this message.  paKet will perform some
                               Page 181

   internal overlays to reduce the memory demands but will still require a
   system with at least 384KB available.

   If you happen to have EMS memory available, paKet will use some of that,
   notably for the Flashback buffers which tend to consume lots of precious
   memory.   But most of the memory required comes from the Base 640KB.

   Try to conserve as much memory as possible because even if paKet runs
   quite happily in the available memory, you might still need more if you
   want to run some external program from within paKet.  For example,
   editing a file will add to the memory demands as the system will have to
   load the chosen Editor program then load the data file you want to edit.
   Or if you take the DOS exit (refer <F9> key) you might find there is not
   enough memory left, after paKet has taken its lot, to run your DOS
   commands.

   There are some things you can do to overcome this "Insufficient memory"
   problem:

      1. If you are one of the few remaining diehards who are running an
         IBM or compatible system with less than 640KB RAM, then the
         solution is easy: "buy some more memory!"

      2. Reduce the memory demands from within paKet by:
            a. configuring fewer Communications Windows (I find 3 plenty
               for my operation). Each of these will consume some memory
               overheads and if you don't really need all 10 windows you
               can save some memory by reducing the number.

            b. configuring smaller buffers for Input and Flashback buffers
               in each of the Communication Windows.

               Most of the time I use only the first window - it is only
               on relatively rare occasions the second window gets used,
               the third window hardly ever. So I tend to configure larger
               buffers for the first window and reduce the others.


    3. Reduce other memory overheads such as TSRs.
         Many people do not realise that Menu programs, Shells, and the
         like that provide a "launching pad" for their programs, usually
         remain in memory while their other program is running. You should
         run paKet from the DOS prompt, by all means from a BATch file,
         but not from a Shell or Menu.

         And any other TSRs such as DOS's Print Spooler, Mouse drivers,
         various Pop-Up utilities such as Calendars and Phone Diallers,
         all consume some memory even if they are not currently being
         used. There are techniques available for some systems now to load
         these things in High Memory (eg the latest versions of MS-DOS and
         DR-DOS, as well as other products such as QEMM provide this
         "load-high" facility). If you can, load as much as possible into
         High Memory to relieve the pressure on the Base 640K. Otherwise
         try removing any unwanted TSRs and drivers before loading paKet.
                               Page 182


      4. Make some EMS memory available.  If you have more than 640KB of
         memory in your system you can usually allocate some of this for
         EMS (sometimes called Expanded memory) and then paKet will use
         that for some overlays and Flashback buffers.

         Refer to your DOS documentation (or to the documentation for the
         memory manager program you are using, such as QEMM, etc) for
         details on how to set up your system for EMS memory.

         If EMS memory is available, paKet will automatically detect it
         and use as much as it can for its buffers etc.  Depending on your
         configured buffer sizes, paKet might use 200 to 300 KB of your
         EMS memory but in any case it will display a message at start up
         time, to inform you it is using EMS memory and telling you how
         much is used and how much is still free.

   Sometimes the lack of memory is not critical.  For example if you are
   loading the Online Manual (refer <Alt-F1> key) and paKet has
   insufficient memory to load that information, you will get the above
   "Insufficient memory" message followed by something like:
      "Continuing without Online Manual..."

   You will not be able to view that Online Manual but at least paKet
   processing can continue (without that facility).



 Insufficient space for this file.

   When receiving a Binary File, paKet will check the file size (once it
   is known) and verify there is sufficient space on the drive to hold the
   file.

   If the file is not going to fit, this will avoid wasted time by
   aborting the transfer before it starts.



 Invalid argument

   This message will appear if you have specified an invalid DOS command.

   Check the command and reenter.



 Invalid FLAG command in Script

   The Script file you have just loaded contains a command beginning with
   F which suggests a Flag command but the syntax is invalid.

   Refer to the section on Script Processing for syntax details.

                               Page 183



 Invalid keyword ignored in CFG file

   This message will appear only if someone has manually edited the
   PAKET.CFG file!  It is best to leave the configuration to paKet's
   online configuration facility.  That way, all changes to the
   configuration will be checked and validated before they are written to
   the file!

   If you don't know how to correct the PAKET.CFG file to get rid of this
   message, you might have to run the INSTALL program again to rebuild the
   file.



 Invalid Message Header.
 Just enter S to leave a message for (your name), (your callsign)
 To leave a message for a particular station, enter 'S (callsign)'
 Note the <space> after the 'S'. Eg: S VK2XYZ

   These messages are sent to a REMOTE user who has typed a command
   beginning with S but it does not conform to the required PMS syntax for
   sending a message.

   These messages are self explanatory but for more information on the
   syntax, check the PMS section of this Manual.



 Invalid path.

   There is something wrong with the path specified.

   For example, this message will be sent to a REMOTE user who has
   attempted to access an invalid directory with a W or D command.



 I/O Error - Bad Request
 I/O Error - Data Error (CRC)
 I/O Error - Drive not ready
 I/O Error - General failure
 I/O Error - Printer out of paper
 I/O Error - Read fault
 I/O Error - Sector not found
 I/O Error - Seek Error
 I/O Error - Unknown command
 I/O Error - Unknown error type
 I/O Error - Unknown media type
 I/O Error - Unknown unit
 I/O Error - Write fault
 I/O Error - Write protected

                               Page 184

   An error has occurred and paKet has attempted to identify the
   particular error. These errors are documented in your computer's
   Operating System documentation and are reasonably descriptive of the
   problem.

   In most cases you will know what is causing the error as you will have
   just performed some function, for example you will have requested a
   directory display from a diskette, or you will have attempted to use
   the printer.

   Refer to your DOS system documentation for further information on any
   action to be taken.

   And refer to the description on the "Abort, Retry, Ignore" message for
   discussion on the options available.







































                               Page 185

Messages starting with K, L and M

 Keystroke ignored.  Press <Esc> to abort the transfer.

   While conducting a Binary File Transfer, you should not be typing any
   other commands and you can't talk to the other station while the
   transfer is in progress, so any keystrokes (except the <Esc> key) are
   going to be ignored.

   This message will pop up if you do happen to type something during the
   Binary File Transfer.   No harm done though.



 Leaving REMOTE mode - returning to Normal Communications.

   This message is sent to a REMOTE user when paKet is leaving REMOTE Mode
   and returning to normal conversation mode.

   It will usually appear if the REMOTE operator types the T(alk) command.



 Leaving the menu...now communicating with (your name) the paKet operator

   If you decide to cancel REMOTE mode with the <F3> key, this message
   will be sent to the other station to let them know they are no longer in
   REMOTE Mode.



 Loading Manual from (filename)
 Loading (TNC Help File Name)

   paKet maintains an index into the Online Manual (and the TNC Help file)
   but if that index is lost of if there is any change to the Manual or
   Help File, the program will reload the manual and rebuild the index so
   it will be quicker next time.

   If the index needs to be reloaded, this message appears to let you know
   it is working and it confirms the name of the file it is loading the
   information from.

   It can take a few seconds, longer if loading from diskette, so you are
   reassured the system is still working.


   If you get an "Insufficient memory" message here, it will be followed
   by a message such as:
      "Continuing without Online Manual..."
   paKet will then continue with normal communications but, of course, in
   that case you will not be able to view the Online Manual or the Help
   File as the case may be.

                               Page 186



 Log file now closed because of file error
 Further input held with <ScrollLock>

   A disk error has occurred while writing to the Log File.

   Perhaps the most likely cause is the disk has run out of space. You can
   delete any unwanted files from paKet's online Disk Directory Window
   (<Alt-D>) ; or you can exit to DOS with the <F9> key and fix the
   problem there.

   If you were logging to diskette, you can replace that diskette and open
   another log file on a new diskette.

   In most cases paKet will automatically switch on <ScrollLock> to hold
   any input data in the buffer until you get the log file going again.
   This way you will not lose anything from the log file.  When you have
   rectified the problem, press <F2> to activate the Log file again (if
   you want to) then press <ScrollLock> to release the data from the Input
   Buffer.



 Looks like a Disconnect?
 REMOTE mode cancelled.

   paKet has detected what looks like a Disconnected message while in
   REMOTE Mode..

   If the other station disconnects we must shut down REMOTE mode because
   if we are going to send the Menu, we must have someone to sent it to!

   The normal procedure would be for the REMOTE user to type B(ye) to end
   the session then everything is closed down tidily.  But if that other
   station simply disconnects or perhaps if there is a problem with the
   radio link, paKet will ensure there are no loose ends to cause any
   problems.



 Maximum 280 lines per 'page'

   When displaying the Online Manual or the TNC Help file, each "chapter
   or section" is retained in memory for quick and easy scrolling. In
   doing this I have imposed a limit of 280 lines for each chapter or
   section.

   This has proven to be quite ample and works fine with the files as
   distributed. So if this message appears, the file is either corrupted
   or has been changed by someone (and, come to think of it, isn't that
   the same thing?).


                               Page 187


 Message file closed by Disconnect

   The other station has disconnected while paKet is receiving a PMS
   message.

   The Disconnect is processed and the Message File is closed to preserve
   whatever part of the message has been received so far.



 Move to the start of the block and press <Enter>
 Move to the end of the block and press <Enter>

   When you press <Alt-W> to write some data from the Flashback Buffer out
   to disk, these messages will pop up to guide you in selecting the data
   you want to capture.

   (For users of earlier versions of paKet, this is new.  Previously you
   had the option to write the entire buffer or none at all, but now you
   can select any part of the Flashback Buffer you wish).

   So, use the arrows to move back through the Flashback buffer to the
   beginning of the block of data, then press <Enter>.  The second of
   these messages will then appear asking for the end of the block.
   Move the highlight bar to the end of the block (note the block is
   highlighted as you move the bar) and press <Enter>.


   Hint:
   If you find the thing beeping at you when you press the arrows it is
   because the message window is still on the screen and you should wait
   for it to disappear.   You can remove that message window before its
   duration has expired by pressing <Esc>.



 Must be .......

   When making changes to paKet's Online Configuration, there are some
   checks performed to ensure the new values entered are valid.  paKet
   will issue a message in the above format to advise you if it thinks an
   error has been made.

   The message will tell you what it expects to see.  For example a
   message might be:
      "Must be between 0 and 250"

   This tells you the value you entered was wrong, and that the correct
   values must fall within the range indicated.




                               Page 188

Messages starting with N

 No files

   This message will be sent to a remote user if a directory display has
   been requested and:

      1. there are no files in the specified directory;  or

      2. if a file specification has been included in the request
         (eg: YW \BIN\*.EXE) this message will be sent if there are
         no files matching that specification;  or

      3. if the directory name is incorrectly specified.



 No further Information available. Sorry.

   When the REMOTE user types "I" for Information, paKet will send the
   contents of REMOTE.INF file from the default directory.

   However, if that file cannot be found, this message will be sent
   instead.



 No HELP available. Sorry.

   When the REMOTE user types "H" for Help, paKet will send the contents
   of the REMOTE.HLP file from the default directory.

   However, if that file cannot be found, this message will be sent
   instead.



 No messages

   This message will appear in response to a PMS command (eg List) if
   there are no messages currently recorded.



 No such file or directory

   This error message occurs after an attempt to Rename or to Move a file
   with the <Alt-R> key.

   It would usually appear if you have specified a new sub directory in an
   attempt to move a file to another subdirectory, but the specified
   subdirectory does not exist on this drive.


                               Page 189


 No, the TNC thinks we are NOT connected!

   After pressing <Alt-V> to verify the connected status, this message
   will appear if paKet thought there was a connection in the current
   window but the TNC disagrees, indicating there is NO connection.

   The Communications Window Header is changed to show "Not Connected".



 No, there's nobody here.  Here's the REMOTE menu back again...

   After the REMOTE user types a T command, paKet will return to normal
   converse mode, optionally sound the bell, and wait for you to respond
   with some keyboard activity. If you have not responded within say 30
   seconds, paKet will return to REMOTE Mode and will send the above
   message before re-issuing the menu.



 No, you may not leave a message for a third party

   In some countries it is still illegal for a message to be addressed to
   a third party.  So there is an option in paKet's configuration to
   disallow third party messages in your PMS.

   If your system is configured this way a REMOTE user tries to leave a
   message addressed to a third party, paKet will refuse to accept it and
   will send this message to the other station.



 Not enough free memory

   The external program you are trying to run will not fit into whatever
   memory is still available after paKet has taken what it needs.

   You might have to return to paKet and exit (<Alt-X> or <Alt-F4)) before
   trying the other program again.



 Not found

   If you have initiated a search through the Flashback buffer for some
   text (via the <Alt-F> or the <Alt-L> keys) the matching text will be
   highlighted.  This message will appear if there is no (more) matching
   data in the buffer.





                               Page 190

 Now I can't find message nn

   This is probably a program bug, so hopefully you will never see it. It
   means paKet is now unable to find a message it was working on earlier.
   If you get this, you'd better let me know!



 Now I can't read the PMS DataBase file!

   An error has occurred trying to do some housekeeping on the PMS
   DataBase file.

   As far as the rest of the paKet processing is concerned, this is not a
   critical error because normal communications can continue without the
   PMS. So normal processing continues.  It is likely you will lose the
   messages that were in the PMS but check it out.





































                               Page 191

Messages starting with P

 paKet Registration
 Please enter your Serial Number

   When you type <Alt-R> to register this copy of the program, or when you
   change the configured callsign, paKet will ask you for your Serial
   Number.  Type the number into the message window that is displayed.

   If you do not yet have your Serial Number, just press <Enter> and the
   program will continue as an unregistered copy.  I assume you are going
   to register so you will always have the full facilities available in
   the copy you have.



 paKet-Protocol Recovery approved
 Issuing approval to the receiver station...

   We are sending a Binary File and the other station has requested a
   Recovery of a partly completed file transfer.

   After checking the details provided by the other station, paKet has
   decided it DOES look like the same file and is sending its approval to
   the other station.  Now both sides can begin the transfer from the
   agreed point in the file.



 paKet-Protocol Recovery approved
 now appending to file...

   We are receiving a Binary File from another station and our system had
   requested a paKet Protocol Recovery.

   This message will appear if the Recovery is approved by the other
   station. The transfer will continue from the point where it aborted
   last time. It will be approved provided the other station is using
   paKet Protocol and both stations agree it seems to be the same file.



 paKet-Protocol Recovery denied
 This does NOT look like the same file

   We are receiving a Binary File from another station and our system had
   requested a paKet Protocol Recovery.

   This message appears if the other station has refused our request for a
   Recovery because it does not appear to be the same file.  The file
   already on our system will be preserved and a new file will be
   transferred in its entirety.


                               Page 192


 paKet-Protocol Recovery denied. The receiver's file does NOT match ours.
 The entire file will be sent from the beginning

   We are sending a Binary File and the other station has requested a
   Recovery of a partly completed file transfer.

   After checking the details provided by the other station, paKet has
   decided it is NOT the same file and is sending a message to the other
   station, refusing the Recovery request.



 paKet-Protocol Recovery requested by the receiver
 Attempting recovery - verifying file contents...

   We are sending a Binary File to another station and that station thinks
   we may have tried this one before, unsuccessfully, because a shorter
   version of the same file already exists on that system.

   Some details of that file have been provided by the other station and
   paKet is now checking to see if it could be the same file.



 Performing AUTOEXEC.SCP
 Performing AUTOEND.SCP

   The AUTOEXEC and AUTOEND Script files are optional.

   If the AUTOEXEC.SCP file is present paKet will run that Script as soon
   as it starts up (immediately after any Begin-Auto commands).  The
   Begin-Auto commands, which may be specified in the Configuration, are a
   simpler way to send any initialisation commands to the TNC but a Script
   provides more flexibility should the need arise. You can have both the
   Begin-Auto commands and the AUTOEXEC.SCP if you wish.

   When you press <Alt-X> or <Alt-F4> to exit the program, paKet will look
   for the AUTOEND.SCP file and if present, it will run that Script before
   any End-Auto commands that may exist in the Configuration.

   The above messages are displayed to inform you these Script files are
   being processed.



 Please check the BBS Connect Path in the PMS Configuration
 This should be a valid Script file name enclosed in pointer brackets.

   According to the configuration file, you want to use a Script to
   establish connection with the BBS but the syntax is invalid for a
   Script File name.  Check the configuration details by typing <Alt-Z>
   then 6.

                               Page 193

   If you specify the callsign and connect path to your BBS, you just type
   the callsign etc. For example:
      VK2ATM-1 v VK2RPM-1

   But if you want to specify a Script file name, it should be entered in
   that Configuration with "pointer brackets".  For example: if the Script
   File is BBSCONN.SCP, it should be specified as
      <BBSCONN>
   (The SCP extension is optional).



 Please close the log file first

   You should not edit a file that is already open and being used for
   something else. DOS gets horribly confused and upset.

   You will get this message if you try to edit the current Log File. If
   you really want to edit this Log file, press <F2> to close it first,
   then try the Edit command again.



 Please enter a Message Number with the command.
 Eg: R 4

   In paKet's PMS, the messages are identified by a number. When you enter
   a command to process a message, the system needs to know which message
   you are referring to.

   Reenter the command, specifying the message number after the command as
   shown in the above example.



 Please include the filename with the command.

   A REMOTE user will get this message if paKet receives a file command
   such as D (download) or U (upload) but the other station has not told
   us which file!



 Please set the BBS Connect Path in the PMS Configuration

   You entered <Alt-F3> to initiate a Mail Forwarding session but have not
   yet set the BBS connect path in the PMS configuration.  So I do not
   know the BBS callsign nor how to connect to it.

   Type <Alt-Z> then 6 for the Configuration Window to record the BBS
   details before attempting a Mail Forwarding session.



                               Page 194

 Please take care with this. RESTART is the command mostly used.
 On most TNCs, RESET will clear everything including your MYCALL!

   This message will appear as a warning when you select the Serial Port
   Configuration and change the item specifying the command to initialise
   your TNC.

   When changing Serial Port parameters, you will usually be changing both
   the TNC's parameters and the computer's parameters and need to keep the
   two devices synchronised in order to maintain communications. The way
   this is done is to send the commands to the TNC first because most TNCs
   will accept the changes but will not actually apply those changes until
   the TNC is re-initialised.  Next, you change the Computer's Serial Port
   parameters.  paKet will then ask you if you would like to initialise
   the TNC and (if you reply 'Y') will send the RESTART command to the TNC.

   This worked fine until I found the Kantronics range of TNCs are
   different to the others and require the RESET command instead of the
   RESTART command! So, in order to offer some support for these devices I
   added a configurable option to use either RESTART or RESET.

   This warning message appears whenever you select RESET because this
   command should be selected ONLY if you have a non standard TNC which
   uses the RESET command in this way!  On all other TNCs the RESET
   command will clear EVERYTHING from it's memory including your callsign!
   You will have to enter all your settings again if you (or the program)
   send a RESET command to the TNC!



 Press any key to return to paKet...

   This message will appear briefly after an external program has been run.

   If you run a DOS command from the paKet screen (refer <F9> key) or
   Display (<Alt-D>) a file, you will often need some time to look at that
   screen before returning to normal communications.



 Pressing <Alt-F6> again will close the file

   This message will appear after you begin a RAW Binary File Transfer
   with the <Alt-F6> key because with this RAW Mode there is no protocol
   being used and you will be expected to close this file manually by
   pressing that same key combination again.



 Pressing <F6> again will close the file

   This message will appear after you begin an ASCII Text File Receive
   operation with the <F6> key. It serves to remind you how to terminate
   the file transfer if the other station does not do so.
                               Page 195


   All data received into this Communications Window will be written to
   the selected file until the other station sends a <Ctrl-Z> to close the
   file and terminate the File Transfer operation.

   If the other station does not send the <Ctrl-Z>, or if you wish to
   close the file part way through, you can press <F6> at any time and the
   file will be closed and the File Transfer terminated.



 Printer is not ready!

   The Printer status indicates it is not ready to accept any print data.

   When the printer is ready, press <Enter> and paKet will continue.

   You may see some additional message text, especially if the Printer Log
   is active:
      "Esc to switch off Printing"
   In this case you could press <Esc> to clear this message and to switch
   off the Printer Log.



 Program error.

   This message will never appear because it refers to a program logic
   error.  It can never happen!

   But er, in previous versions some of these "can never happen" messages
   have appeared so I thought it best to include a reference them in this
   Manual.

   If you do get one of these it indicates something like
      "Config Help already loaded."
   which is telling us the program tried to load this help file when it is
   already loaded.  That can never happen, can it?   But uh, just in case
   it does, you had better let me know about it.















                               Page 196

Messages starting with R

 Ready to receive ASCII text file...(Ctrl-Z to end)

   A REMOTE user has commenced an ASCII file upload to our system with the
   U command.

   This message is sent back to acknowledge that command.



 Ready to receive binary file using paKet Protocol...
       or
 Ready to receive binary file using YAPP protocol...

   When a REMOTE user initiates a Binary File Transfer to our system with
   the YU command, paKet will send back this acknowledgement if it is
   ready and able to receive the file.

   The content of this message is determined by your configuration setting
   as to whether or not you wish to allow the use of paKet-Protocol (pP).
   Even if it does indicate the use of pP, the transfer might still be
   conducted using standard YAPP protocol if the other station supports
   only that method.



 Ready to send binary file using paKet Protocol...
       or
 Ready to send binary file using YAPP protocol...

   When a REMOTE user initiates a Binary File Transfer from our system with
   the YD command, paKet will send back this acknowledgement if it is
   ready and able to send the file.

   The content of this message is determined by your configuration setting
   as to whether or not you wish to allow the use of paKet-Protocol (pP).
   Even if it does indicate the use of pP, the transfer might still be
   conducted using standard YAPP protocol if the other station supports
   only that method.



 Receive file now closed

   An EOF (i.e. a <Ctrl-Z> character) was received while receiving ASCII
   file.

   Normal condition - no action required.

   This message can also appear if the other station disconnects without
   closing the ASCII file we are receiving.


                               Page 197

 Receiving ASCII file
 Script command 'AC' will close the file

   This message appears if you are running a Script and there is an AD
   command which is processed to open a text file to receive any incoming
   data.

   The normal process would be for that same Script to close the file with
   an AC command somewhere else in that Script file, but the message
   alerts you to the fact that the file is open.  You can close it
   yourself (with the <F6> key) if necessary.



 Receiving Binary file FROM BayCom
 Enter the file name in the BayCom system:

   When you request a Binary File transfer from a BayCom system, paket
   needs to know details of the file so it can generate the required
   commands to send to that system. If this command is used with Digicom
   (some versions), that system's name for the file may be one containing
   blanks or other oddities incompatible with a MS-DOS filename.

   If the BayCom system has the desired file in another directory you
   should also specify its sub directory name. For example if the file you
   want is called MYPROG.EXE and it is stored in the BayCom system's PRG
   directory, you would enter:
      PRG\MYPROG.EXE

   If it responds with a "file not found" error message, check the
   directory details with the BayCom operator. A common cause of this
   error would be if you inadvertently specify a leading "\", eg:
      \PRG\MYPROG.EXE

   This message will then be followed by:
      What should I call it here?

   paKet wants to know what name to give the file here on our system. You
   might normally use the same name as that in the BayCom system, but you
   can change it if you wish.

   And finally, the following message appears to ask for the file size:
       Now please enter file SIZE in bytes (-1 for Digicom):

   You should enter the size of the file you are transferring because the
   BayCom system may not tell us when the transfer is complete. The BayCom
   operator should be able to tell you the file size. If you do not know
   the file size in BYTES, enter 0 (zero), but in that case you will have
   to close the file manually.

   If you are trasnferring a file from a Digicom, enter -1 for the file
   size to tell paKet it is a Digicom transfer. You will still have to
   close the file manually.

                               Page 198


 Receiving RAW Binary file
 Enter the file name:

   We are about to receive a file using the RAW Binary File Transfer
   method.  As this method has no file transfer protocol at all we have to
   do everything ourselves, including identifying the name of the file.


 REMOTE deactivated by Disconnect

   The usual way to log off from REMOTE is to enter B for Bye or T for
   Talk.  This message indicates the connection has been severed by a
   Disconnect command to the TNC at either end.

   No harm done and no action is required.  paKet will close down the
   REMOTE system and return to normal mode.



 REMOTE is available only while Connected

   You have pressed <F3> to place paKet into REMOTE mode and to issue the
   Menu to the other station, but paKet thinks we are currently not
   connected, so there is no other station to send the Menu to!

   Try it again after a connection is established.

   Occasionally paKet might fail to detect the connection and although you
   are really connected to another station, paKet shows "Not Connected" in
   the Communications Window Header Line.

   If this has happened you will not be able to enter REMOTE mode. You can
   correct this by pressing <Alt-V> to ask paKet to verify the connected
   status with the TNC. If this changes paKet from "Not Connected" to show
   a callsign in the Communications Window Header, you can then try the
   <F3> again.



 REMOTE Mode cancelled

   At times things can go wrong with a Binary File Transfer.  There are a
   multitude of possible causes, but the effect is that one station
   continues to send while the other end, the receiving end of the
   connection has aborted the transfer and is back in the REMOTE Menu.

   When the sending station sends another block of data, the poor guy with
   the REMOTE Menu sees all these funny "commands" coming in and sends
   back a whole lot of "*** Invalid option" messages!

   So if paKet sees several of these "*** Invalid option" messages go out
   in quick succession, it will shut down REMOTE Mode, display this
   message, and wait for things to settle down.
                               Page 199



 Returning to normal communications...

   You pressed B (Bye) after using the Sysop PMS Menu. This will release
   the <ScrollLock> condition and the system reverts to normal
   communications mode once again.



 Running under OS/2
 Running under Windows
 Running under Windows Enhanced Mode

   While testing under these different environments, I displayed these
   messages to confirm the program recognised the particular environment
   it was running under at the time.  It was my vague intention to see
   what enhancements could be added to gain better performance from the
   multi tasking systems.  (Needless to say, that didn't get done.)

   Maybe in another release, I will find time to enhance the paket system
   so it performs better in a multi tasking system.  This version does
   work well with the above systems but has not been enhanced to take
   advantage of the facilities offered by any particular operating
   environment.

   I was going to remove these messages after initial testing once I was
   satisfied the program correctly detected the situation.  However,
   despite the small overhead, I decided to leave them in.

























                               Page 200

Messages starting with S

 Saving configuration parameters in PAKET.CFG

   If you make any changes to paKet's Configuration, the changes are saved
   to disk automatically.

   This message confirms the action taking place.



 Script file not found

   After starting Script Processing with the <Alt-S> key, you have entered
   a Script file name, but paKet cannot find that file.

   Usually you would select a Script from the Directory Window so this
   message would be rare.  However, if you have manually entered the file
   name, check the spelling and ensure you have entered any subdirectory
   details if necessary.



 Script label not found

   A Script command specifies a Script label but paKet cannot find that
   label in this Script.  Refer to the Script Processing section of this
   Manual for details of Script syntax.



 Script Performed successfully

   This message is sent to a REMOTE user after the successful performance
   of a Script via the P (Perform) command.

   Note however, a successful Performance means the Script completed
   without syntax errors etc.  It does not necessarily mean the Script has
   done everything expected of it.  For example if it was to transfer a
   file and that file could not be found, paKet might have issued an error
   message about the file not found, but as far as the Script processing
   is concerned, the Script has now completed successfully because it
   performed every one of the commands it was asked to Perform!

   It is up to you, or the Script programmer, to ensure adequate messages
   are issued from the Script itself to inform the REMOTE user of
   progress for that particular job.



 Script Processing Aborted

   If paKet detects a serious problem in your Script file, the Script will
   be aborted and paKet returns to normal communications mode.
                               Page 201


   This message alerts you to the fact that the Script has NOT been
   completely executed.



 Script UNSUCCESSFUL!  Ask (your name) to check the Script

   A REMOTE user has issued the P command to Perform a Script but paKet
   has failed to complete the Script successfully.  The reason is possibly
   a fault in the Script code itself.

   The REMOTE user gets this message but if the problem is in the Script
   file, you will have to attend to that yourself.  The REMOTE user cannot
   fix that remotely.



 Searching for available Script files...

   If a REMOTE user enters a P command without specifying the name of the
   particular Script File to perform, paKet will send back this message
   while it goes searching for all the files with an SCP extension in our
   Script directory.

   Then it will send the details of those filenames to the REMOTE station.



 Sending Binary file TO BayCom
 Enter the file name in the BayCom system:

   When you request the transfer of a binary file to a BayCom system,
   paKet will ask for the name you want to give this file when it is
   written to the BayCom system. (You can send to some Digicom versions
   also).

   Usually it would be the same as the file name in our system but you can
   change it if you wish.

   Another reason for this message is to allow you to specify a
   sub-directory as well as a file name for the BayCom system. For
   example, say we are sending the file UTIL.EXE to a BayCom system and we
   want to write it to the BayCom user's PROG sub directory. So, in
   response to the above message you would enter:
      PROG\UTIL.EXE
   Of course paKet does not know what sub directories are available on the
   BayCom system - that is your job to find out.






                               Page 202

 Setting KISS Mode OFF. Sending these codes to the TNC:
 nnn nnn nnn

   If you press <Alt-K> to set KISS Mode off, this message appears to show
   you the codes being sent to the TNC.

   Refer to the  <Alt-K> key in the Keyboard Commands section of this Manual
   for further discussion on resetting KISS Mode.



 Sorry, but this station does not accept Uploads

   This message is sent to a REMOTE user who types a U, MU or YU command
   to attempt to upload a file to this system, but you have disallowed
   file uploads in your Configuration options.



 Sorry, but this station does not allow Downloads

   This message is sent to a REMOTE user who types a D, MD or YD command
   to attempt to download a file from this system, but you have disallowed
   file downloads in your Configuration options.



 Syntax error in Script line.

   The Script file currently being processed has a syntax error.  Details
   of the line are give to help you identify the fault.  For example the
   message might include additional information such as:
      "(no comma)"

   Some Script command require two fields separated by a comma and if that
   comma is not found, the Script process will abort with that message.

   Refer to the section on Scripts in this Manual for full details of
   Script syntax.



 Sysop PMS menu: <B,C,E,H,K,KM,L,LM,R,RM,S,?>

   This is the menu that appears when you press <Alt-M>.

   The PMS sub system is discussed in its own section of this Manual.







                               Page 203

 Sysop PMS Menu Help...
    B  (Bye)       - End Sysop PMS Processing
    C  (Copy)      - Copy a message to a file (eg C 3)
    E  (Edit)      - Edit a message header (eg E 3)
    H  (Help)      - Display these details
    K  (Kill)      - Kill a message (eg K 3)
    KM (Kill Mine) - Kill all messages addressed to me
    L  (List)      - List available messages
    LM (List Mine) - list all unread messages addressed to me
    R  (Read)      - Read a message (eg R 3)
    RM (Read Mine) - Read all unread messages addressed to me
    S  (Send)      - Send a message (eg S VK2XYZ)
    ?  (Help)      - Display these details

   This list of commands is available only from the Sysop PMS Menu. It
   appears in response to the H or ? command.

   Further details of each of these commands are given in the section on
   the Personal Message System in this Manual.



 System Note at HH:MM:SS - msg

   A System Note is an information message that is a little different to
   other information messages in that it appears in the Communications
   Window (and optionally in the log file) rather than in the popup
   Message Window.

   These System Notes are mostly used to log information on the success or
   otherwise of a file transfer.  These file transfer operations can be
   time consuming and the operator might start the transfer and go do
   something else while the file being transferred.  So a brief popup
   message might not be seen and it was felt a more permanent record was
   required.

   Of course no action is required, as this type of message is designed to
   cater for those situations where the operator might not be present
   anyway.

   The HH:MM:SS is the computer's time when the System Note is issued.
   "msg" should be self-explanatory. For Example:
      "Upload successful - FILENAME.DAT"











                               Page 204

Messages starting with T

 Thank you.
 Recording your Serial Number...
 This copy of paKet is now Registered.

   A note of appreciation to those who do the right thing.



 That directory is not available. Sorry.

   This message is sent to the REMOTE user who has entered a command to
   access one of our directories but that directory name is either invalid
   or inaccessible to the REMOTE user.



 That's not the correct Serial Number.

   When you enter your Serial Number, paKet will check it for validity and
   let you know if it does not check out.

   No harm done, just try it again.

   If you find there must be something wrong with the number you have,
   contact me or your official paKet distributor.  In the meantime, you
   can continue to operate the paKet system with full facilities
   available.



 The BBS is not responding

   You tried to initiate a Mail Forwarding session with the BBS but the
   TNC failed to establish a connection with the BBS within a reasonable
   time.

   That "reasonable" time is currently set to 60 seconds for a direct
   connection and to 4 minutes in the case of a connect path which
   includes digipeaters or network nodes.

   Those times should be quite sufficient in normal circumstances. In
   case of some temporary problem, just press <Alt-F3> when you think
   things are back to normal and paKet will try again to connect to the
   BBS and conduct a Mail Forwarding session, sending any mail waiting in
   your PMS and taking any incoming mail the BBS wants to send.



 The EOF has not been acknowledged.

   We are sending a Binary File with pP or YAPP Protocol and have sent the
   last byte followed by the End-of-File code.  The other station should
                               Page 205

   then acknowledge that code so we know the transfer has successfully
   completed.

   This message appears if the EOF acknowledgement has still not arrived
   after the specified delay has expired. (2 minutes is the time specified
   in the YAPP Protocol specifications and is the default paKet setting).

   When paKet has sent the last byte and the EOF code, it starts counting.
   In most cases 2 minutes is plenty of time for the other station to get
   the last of the data and close the file there before sending its
   acknowledgement.  However, if your TNC is equipped with a large buffer
   your TNC might still have a significant part of the file still in its
   buffers waiting to be transmitted.  paKet doesn't know about that and
   thinks it finished when it sent the EOF to the TNC!  It could easily
   take more than 2 minutes for the TNC's buffer to be cleared.

   This message will pop up to warn you we are still waiting for the
   acknowledgement.  But, provided paKet is not in REMOTE mode, the
   following message will also appear:
     Continue waiting for another  nn  minutes.  (Press <Esc> to Abort)

   You can choose to wait for the time shown just by pressing <Enter>.

   But you can change that time so if you do happen to have a TNC with a
   large buffer, you might like to change the default value of 2 minutes
   to something larger to suit your particular TNC.  paKet will remember
   the new value, so if you change it to (say) 5 minutes, paKet will wait
   for 5 minutes next time before telling you the EOF has not been
   acknowledged.

   The same messages will reappear at the end of that time if the
   acknowledgement has still not arrived.

   If you press <Esc> the transfer will be aborted in accordance with the
   original YAPP specifications.

   If our paKet system is performing this Binary File transfer in REMOTE
   mode, you may not be around to answer the question. In that case the
   following message appears:
       "but as I am in REMOTE mode I will continue waiting..."

   and paKet will start another timeout period.  It will do this 3
   times (i.e if the default delay is 2 minutes, paKet will wait a total
   of 8 minutes) before aborting.



 The message file was not closed

   The other station started to send a message to our PMS but has
   disconnected without completing the message.

   paKet has closed the message file so the message, or at least that part
   that we had received, will be retained.
                               Page 206




 The PMS data file is missing, so all messages are lost!
 The PMS index is missing so all messages are lost!

   paKet's PMS is stored in two files, a data file which contains the
   content of the messages in the system; and an index file which contains
   just the message headers and an index into the data file.  The two
   files are PAKETPMS.DAT and PAKETPMS.IDX.

   If one of these files are missing, or if the Operating System is unable
   to open the file, one or both of the above messages will be displayed.

   Both files are required for the PMS system to work.  So if one of them
   is OK and one is bad or missing, there is not much point in keeping the
   good one!  You might as well consider them both bad and start again.

   This problem is possibly be due the the files being unavailable for
   some reason. Possible reasons include:

     1. you have deleted them;
        If so, that's tough! You've lost any messages that might have been
        in the PMS. If the data file alone is still there, you can get a
        fair idea of the messages by reading it though.

        You could restore the TWO files from a recent backup?


     2. the Configuration file has been changed and paKet can no longer
        find the files;
        In this case, you should change the Configuration by entering
        <Alt-Z> then selecting option 8 (Directories and Files) to
        correctly specify the location of the PMS files.


     3. The PMS files are on a diskette and that diskette is not in the
        drive.
        I don't think you need me to tell you what to do here. I'll leave
        you to figure this one out on your own.



 The other station seems to be in paKet REMOTE mode too.
 REMOTE mode cancelled!

   The other station has sent what looks like the paKet REMOTE menu while
   our system is also in REMOTE mode.

   Our REMOTE system expects to get one of the valid menu commands but if
   instead of one of the valid commands, it receives the other guy's menu
   it will respond with an "*** Invalid option" message followed by
   another copy of our Menu.

                               Page 207

   The other guy is going to do the same when he gets our Menu and they
   would happily go on all day sending each other these "*** Invalid
   option" messages and Menus!

   REMOTE mode is now disabled on this system to avoid the loop and the
   unnecessary exchange of error messages.



 The Serial Port has been adjusted.
 Would you like me to send a RESTART to the TNC, now? (Y/N)
 I assume you have ALREADY set the TNC's parameters.

   These messages appear after you make some change to the computer's
   serial port via paKet's Online Configuration Window.

   Usually when you change one of these parameters, you should change the
   setting in the TNC too because if the two devices are not using the
   same settings they will not communicate.  The trick is to get them both
   changed at the same time.

   The recommended method is to:
     1. send the required commands to the TNC to change the TNC settings;
     2. then make the change in paKet's Configuration.

   Most TNCs will note the requested change but will not apply certain new
   settings until a RESTART command is issued.

   So, after changing paKet's Configuration, paKet will optionally issue
   the RESTART command to the TNC to enable both devices to now continue
   with the new settings.


   Some TNCs, such as the Kantronics range, use the RESET command instead
   of RESTART so paKet has a configurable option (refer Serial Port
   options) and will send either RESTART or RESET depending on the option
   you choose.



 The TNC does not appear to be ready

   paKet is trying to send a character from a string of data to the TNC,
   but the TNC is unwilling to accept it at this time.

   paKet will wait up to 10 seconds without complaint, but any longer
   suggests a possible problem, so this message will appear to warn you.

   After this message appears, that character will be sent to the TNC
   anyway as in most cases the TNC will have an input buffer of 80 free
   bytes or more and the character will not be lost.

   If the TNC is still locked after another 10 seconds, the next character
   will cause the message to be repeated.
                                Page 208


   This message should appear quite rarely as under normal conditions you
   will not fill the TNC's buffers. If you are doing file transfers the
   buffers could fill but special handshaking logic in that part of the
   program will take care of it under those circumstances. If you have
   filled the buffers with lots of KB Macros, then slow down a bit!

   The only action you need to take here is to ensure the TNC and radio
   are functioning normally, and slow down if you are pumping in a lot of
   data from a Script or Macros.












































                               Page 209

Messages starting with T (cont)

 The TNC is not responding.
 Abort, Retry, Ignore  R

   When the program first starts up, it will attempt to establish
   communications with the TNC by sending the following:
      <Ctrl-X>
      <XON>
      DAYTIME command (if that option is enabled)
      any Begin Auto commands
      AUTOEXEC.SCP (if it exists)

   If it gets no response, the above message will appear to alert you to
   the possibility the TNC might not be switched on or the cables might
   not be properly connected.

   There are three options: A, R or I.
   A  is to ABORT the program and return to DOS. In this case, paKet will
      simply give up and you will see the DOS prompt reappear (or the menu
      if you started paKet from a menu).

      You may decide to take this option if you find something wrong with
      the TNC or its connections and prefer to do something else with the
      computer while you attend to those problems. It is a quick and easy
      way out if communications with the TNC cannot be established.


   R  is the RETRY option. If you can fix the problem that caused this
      message to appear, selecting the RETRY option will allow paKet to
      try again and continue as if the problem had not occurred.  Of
      course if you have not really fixed the problem you will get the
      message again!


   I  will IGNORE the problem and paKet's processing will continue.

      Normally I recommend against the Ignore option when an error occurs,
      however in this case it may be desirable to Ignore the error and let
      paKet to continue, despite the lack of communication with the TNC.

      An example of this situation is where the problem is caused by a
      mismatch in the Serial Port settings. Either the TNC or the Computer
      must be changed to allow normal communications to take place. It is
      easier to change the Computer (paKet in this case).

      Type "I" to Ignore the errors and when the Initialisation is
      complete, you can select the Online Configuration's Serial Port
      Window to make the necessary changes. If you do this, don't forget
      the TNC's Date/Time may not be set and the usual initialisation
      commands may not have been processed by the TNC.

      Whenever I get into this situation, I make the necessary changes,
      then exit the program so I can make a good, fresh start.
                               Page 210


      This "Ignore" option will also allow paKet to be used for serial
      communications with something OTHER than a TNC!  (e.g., a telephone
      modem)



 (The upload directory is on another drive - nnn,nnn bytes free there)

   When a REMOTE user asks for a directory display with the W, MW or YW
   commands, paKet sends the file details from your Download directory
   (that is your Send directory) followed by the space remaining on that
   drive.

   But if you happen to configure your Send and Receive directories on
   different drives, the REMOTE user will not know how much free space you
   have on your other (Upload) drive.  That might be relevant because if
   he wants to send a file to us, he might want to know if it will fit.

   So if that happens to be the way you have configured your directories,
   paKet will send this message after the rest of the directory display so
   the REMOTE user knows how much free space you have on the other drive
   too.



 The YU command is sufficient - there is no need to specify a file name.

   If a REMOTE user wants to send a Binary File to us using the YAPP or pP
   Protocol, there is no need to specify a file name with the YU command
   because the Protocol includes details of the file being sent.

   So if a YU command is received with a filename, paKet will send back
   some friendly advice in the form of this message.

   No harm done - paKet continues with the YU command, ignoring anything
   else on the command line.



 This Connected message is ignored because DCD line is LOW.
 (Check the DCDCON option in Configuration/Serial Port window)

   A "Connected" message has appeared in the Communications Window but has
   been ignored because the DCD line is still low.

   paKet uses the TNC's Connected message to determine when and to whom we
   are connected.  Occasionally some text is monitored that looks like a
   Connected message and paKet gets confused, thinking there is a new
   Connection.

   If the DCDCON option is ON in the TNC, paKet can check the DCD "light"
   to confirm we really ARE connected now.

                               Page 211

   If a Connected message is detected but the DCD line is still low, paKet
   will treat that text as plain data and will display this message to
   advise you of the decision taken.

   Refer to the discussion on the DCDCON option in Configuration - Serial
   Port options and refer to the <Alt-V> key for more discussion on this
   issue.

   This feature is not used if you are using Software Handshaking.



 This file already exists.
 A new file, (filename), will be created.

   When receiving a file, paKet will check to see if the file already
   exists and if it does, paKet will issue this warning message.

   The original file will not be tampered with; instead paKet will create
   a new file, using the same file Name but with a new Extension. It will
   try to create a new file with an extension of .000 and if THAT file
   exists, it will try .001 etc. When it finds a filename/extension that
   does not already exist it will advise you of this filename in the above
   message.

   For example, if you are about to receive a file "TEXTFILE.DAT" and it
   already exists, paKet will create a new file "TEXTFILE.000".

   This is also done if you are receiving a Binary File with the pP
   protocol and paKet decides a Recovery of an existing file is not
   possible.  It will transfer the entire file to our disk using this new
   filename.



 This looks like a Script File Name!
 The previous (Script) option is changed to Y

   In the REMOTE/PMS Configuration you may specify the name of your home
   BBS as well as details on how to establish connection with that BBS for
   the purpose of Mail Forwarding.

   In some cases the path to that BBS is complex, involving a number of
   Network Nodes so a simple callsign and digipeater is not always
   convenient.  So paKet has an option to use a Script file instead of a
   "simple" connect path for this BBS connection.

   You will see in that part of the Configuration an option to "Use Script
   to make BBS connection?" and if that is set to N you should specify the
   BBS callsign and optionally any digipeaters your system needs to
   connect to that BBS.

   But if you specify Y to that configuration option, paKet expects to
   find a Script filename instead of the callsigns etc.   The correct
                               Page 212

   syntax for specifying a Script file name is to include the file name
   within pointer brackets, for example"
      <BBSCONN>

   If there is some conflict in the syntax, paKet will try to correct it
   and alert you to the problem with the above message.



 This new value will take effect next time you run paKet

   After making some changes to paKet's Configuration you may see this
   message to remind you that the changes you have made will not take
   effect immediately.

   There are some things that have to be accomplished at the beginning of
   the program, for example the allocation of memory for buffers. So if
   you want to change these things, you will have to exit and restart the
   program for the changes to become effective.



 This subdirectory is not empty!

   When the Directory Window is displayed you may perform some file
   management functions including deleting a file or sub directory.

   You will get this message if you attempt to delete a sub directory that
   in not empty.  You will have to go into that sub directory and delete
   any files in there before we may delete the sub directory name itself.



 Too many arguments

    This message will appear if you have specified an invalid DOS command.

    Check the command and try again.



 Too many connect entries

   There are too many entries in the Connect File and the program cannot
   hold any more. At the time of writing there is provision for 200
   connect entries.

   Delete any unwanted entries and if you really need more, you could
   establish more than one Connect File, specifying the chosen file name
   in the Configuration as required.




                               Page 213

 Too many files

   This message will appear if you have selected a function that tries to
   display the paKet Directory Window, and paKet finds more than 400 files
   in this particular directory or subdirectory.

   I have reserved space within paKet for handling directories containing
   up to 400 files. If you have a directory or sub directory with more
   than this number you will not be able to display that directory with
   paKet's Directory windows.

   I think the limit of 400 files is reasonable as there are certain
   inefficiencies in DOS's handling of very large directories.

   If you get this message, maybe it is time for a bit of housekeeping?



 Too many PMS messages here.

   I have allowed for a maximum of 200 current messages in your PMS. It is
   supposed to be a PERSONAL System and I think 200 CURRENT messages is
   more than ample for a Personal Message System.

   Anyway, paKet can't hold any more so you will have to remove some of
   these to make room for any further messages.



 Too many sections in the Online Manual

   This error message means there are more index entries in the
   documentation file (the Manual) than I have allowed for.

   It is unlikely you will see this message, because I have tested all
   sections of the Manual before releasing this version.  If you do it is
   because someone has modified the Manual since I released it.

   Get a valid copy of the Manual from the original diskette or from your
   backup copy.



 Too many Traps in Script.

   The Script file you have just loaded contains more than 30 Traps.

   Script processing will continue with only the first 30 Traps active so
   be warned it may not be doing quite what you want!

   Refer to the section on Script Processing for details.



                               Page 214

 TRAP in Script ignored.

   You must specify 2 fields separated by comma!

   The Script file you have just loaded contains a command beginning with
   T which suggests a Trap command but the syntax is invalid.

   Refer to the section on Script Processing for syntax details.



 Type ahead buffer is full.
 Press <Enter> to send it or <Ctrl-Del> to clear it

   The Type Ahead buffer is limited to the number of lines visible on the
   screen.  So if you have configured a two-line Type Ahead Window, you
   have a buffer capacity of two lines.

   When this buffer capacity is filled, paKet will not accept any further
   characters and you must either type <Enter> to send that buffer to the
   TNC or type <Ctrl-Del> to clear the buffer (without sending it).

































                               Page 215

Messages starting with U, V and W

 Unknown Script command

   There is a limited number of commands known to the Script sub system.
   They are mostly single character commands and are covered in the
   section on Script processing.

   You will get this message if paKet finds a line in the Script that does
   not begin with one of the valid commands.



 Unknown state in YAPP processing

   The YAPP specifications provide for a variety of conditions which the
   program must cater for but if there is a problem in the logic at some
   stage this message could occur. It is really a program bug so I hope
   you never see it!

   If you do see this message, the current Binary Transfer will most
   likely be unsuccessful. Try it again and if it still fails, you'd
   better let me know so I can attend to it. If you could arrange a copy
   of the file too that would help with my debugging.



 Upload Cancelled

   During a Binary File Transfer you might decide to abort the transfer by
   pressing the <Esc> key.  paKet acknowledges that request with this
   message.



 Upload commenced

   This message is displayed in a System Note at the beginning of a Binary
   File transfer.



 Upload Successful
 Upload UNSUCCESSFUL

   At the completion of a Binary File Upload, this message is issued in
   a System Note to confirm the results.

   If unsuccessful the message will often include a reason for the
   failure.




                               Page 216

 Uploaded Script file renamed with .SSS extension

   This version of paKet has an option in the REMOTE Menu for a REMOTE
   user to Perform a Script on our system.  The Scripts available to a
   REMOTE user are those .SCP files in our Scripts directory.

   A Script may contain a wide variety of commands including DOS commands,
   so it is conceivable a Script could contain commands to do a lot of
   damage to your system including Formatting disks etc!  So be careful
   just what Scripts you make available to REMOTE users.   If you want to
   keep all your Scripts in the same directory, rename the private ones
   with an extension of something other than .SCP then the REMOTE users
   will not be able to see them nor access them.  You can still run the
   Script, regardless of its extension.

   I was concerned that someone might want to create a mischievous Script
   of their own, upload it to our system and Perform it here.   If we
   allowed that to happen, it could do untold damage to our system.  Even
   if their intention was good, we might still not want others to do just
   anything they want with our computer system - they could accidentally
   upset things.

   You could arrange your directory structure so that your upload
   directory was in another path to your Scripts directory, so any
   uploaded files including Scripts would be out of the way and could not
   be performed anyway.

   But just in case... paKet will change ANY file being uploaded to this
   system if it has a file extension of SCP, and modify it to SSS.  That
   way, the Perform command will not recognise it and so it cannot be
   performed by a REMOTE user until you change its extension back to SCP.



 Using EMS Version n.n
 (nnn KB used by paKet - nnn KB still available)

   As the program starts up, it looks for any available EMS memory and
   will use some of it for buffers and program overlays, if it can.

   This message appears to let you know what the program is doing.



 WAIT in Script needs time and a string separated by ,

   The Script file you have just loaded contains a command beginning with
   W which suggests a Wait command but the syntax is invalid.

   Refer to the section on Script Processing for syntax details.




                               Page 217

 We seem to be in Command mode.
 REMOTE mode cancelled.

   The TNC should not be in Command mode while paKet is in REMOTE mode.

   If paKet is in REMOTE Mode it will be issuing the REMOTE Menu. If the
   TNC is in Command mode the Menu will not be transmitted to the other
   station, but will be taken by the TNC as some sort of "command" and
   will be rejected with "What?" or "Eh?" etc.

   REMOTE mode is now disabled so you can perform your TNC commands.

   When you have finished with the TNC's Command mode, place the TNC back
   into CONVERSE mode and, if you then want to issue the REMOTE Menu to
   the other station, press <F3>.



 We seem to have lost DCD. REMOTE cancelled.

   paKet was in REMOTE mode and the DCD line goes low, indicating the
   connection with the other station has been lost.

   In normal circumstances paKet detects the "Disconnected" message when
   the other station disconnects, and will automatically deactivate REMOTE
   mode (if the other station has not logged off normally).

   paKet will also monitor the state of the DCD line during REMOTE
   operations because if you are using Hardware Handshaking, the DCD line
   can be used by the TNC to indicate the other station is still
   connected. So, if the DCD line goes low, paKet will disable REMOTE mode
   and will issue this message to inform you of the action taken.

   This will only occur if you have specified the use of the DCDCON option
   in the Configuration - Serial Port options.



 We seem to have lost DCD. Transfer cancelled.

   During a Binary File Transfer paKet checks the state of the DCD line at
   regular intervals to confirm we are still connected to the other
   station.

   Of course this happens only if you are using Hardware Handshaking and
   if you have enabled the DCD option in the Serial Port options.

   If the link fails during the transfer, it is possible the program will
   not know about it and will continue to send the file to no one in
   particular!   This precaution helps to avoid some embarrassment.

   The above message is issued to let you know what the transfer has been
   cancelled.

                               Page 218


 Which Drive?

   This question appears after you select "Change to another drive" from
   the Directory Window.

   Enter a valid drive letter, it may be either Upper or lower case and
   the colon is optional.



 Without the filesize I won't know when the transfer is finished
 So, when your system has finished sending the file, type the following:
 <CR>//WPRG OFF<CR>
 (the <CR> is the Enter key).
 When I receive that I'll close the file; then I'll send the Menu again.

   These messages are sent to a REMOTE (BayCom) user when a Binary File
   Transfer to our system is about to commence, if the size of the file
   has been entered as 0 (zero).

   This is telling him to type the "// WPRG OFF" command on a separate
   line when his system has finished sending, because that is the
   end-of-file string used by the BayCom system and so that is what paKet
   will be looking for to close the file.



 Without the filesize I won't know when the transfer is finished
 You will have to close the file manually (with <Alt-F8>)

    This is very similar to the previous message but this time it is not
    the REMOTE user that has initiated the file transfer request.  You
    have done it yourself with the <Alt-F8> key to transfer a file from a
    BayCom system but you have entered a file size of zero.

    This message reminds you it is up to you to close the file when you
    think the transfer has finished. It is quite likely the BayCom system
    will simply stop sending when the last byte has been transmitted -
    there may be no indication from that station that the transfer is
    finished.



 Write Flashback buffer to disk
 The LOG file is open - add to this LOG file? (Y/N)

   If the log file is currently open when you select <Alt-W>, paKet will
   give you the opportunity to write the extracted Flashback data to the
   existing log file so you can keep it all together.

   If you wish to do this, reply "Y".   If you reply "N", paKet will ask
   you for details of the file that is to contain the contents of the
   buffer extract.
                               Page 219

Messages starting with Y and Z

 YAPP command must be YD or YU

   This message could appear if you have specified a "Y" command in a
   Script but the command is invalid.

   Refer to the section on Script Processing for syntax details.



 YAPP command must be YW, YD or YU.

   If a REMOTE user types a command beginning with Y, paKet expects it to
   be one of the "YAPP" (or Binary File Transfer) commands.

   However, in this case the second letter was not W, D or U so the
   program considers it invalid and sends this message back to the other
   station.



 You are not allowed access to that message

   This message appears when someone tries to Read or Kill a message in
   our PMS but that message is not addressed TO that station nor sent BY
   that station.  In other words it is not THEIR message!



 You can close the file manually with <Alt-F8> if you wish

   When receiving a Binary File from a BayCom system, paKet may not know
   when to close the file because the BayCom system may not indicate when
   the transfer is complete.

   If paKet knows the size of the file, it can close the file after that
   number of bytes have been received but sometimes the file size is not
   known.  In these cases it is up to the operator to close the file
   manually by pressing the <Alt-F8> key.

   This message pops up to remind you of this option if nothing has been
   received from the BayCom system for a while.  I figured that if the
   other station has stopped sending maybe it has finished?  However the
   decision is yours and yours alone!



 You may specify a DIRECTORY if necessary, but a DRIVE is NOT permitted

   A REMOTE user may specify a sub directory name when accessing our
   system to display the directory or to Download a file.  But for your
   protection, I decided to disallow the ability to specify another drive.

                               Page 220

   If a drive is specified in the command entered, this message will be
   sent back to the REMOTE station.



 You must specify the other station's callsign.

   When a REMOTE user enters a message in our PMS, all that is required is
   the S command because paKet will assume the message is for you unless
   some other callsign is entered.

   But when you enter a message into your own PMS, the program has no idea
   who it is for so you have to enter a callsign with the S command!









































                               Page 221























                      (This page intentionally blank)































                               Page 222